home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / answers / comp / unix-faq / shell / intro < prev    next >
Internet Message Format  |  1994-04-03  |  10KB
  1. Path: bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv
  2. From: tmatimar@empress.com (Ted M A Timar)
  3. Newsgroups: comp.unix.shell,news.answers,comp.answers
  4. Subject: Welcome to comp.unix.shell [Frequent posting]
  5. Supersedes: <unix-faq/shell/intro_764163686@rtfm.mit.edu>
  6. Followup-To: comp.unix.shell
  7. Date: 3 Apr 1994 16:43:09 GMT
  8. Organization: Empress Software
  9. Lines: 208
  10. Approved: news-answers-request@MIT.Edu
  11. Distribution: world
  12. Expires: 1 May 1994 16:39:37 GMT
  13. Message-ID: <unix-faq/shell/intro_765391177@rtfm.mit.edu>
  14. NNTP-Posting-Host: bloom-picayune.mit.edu
  15. X-Last-Updated: 1994/01/18
  16. Originator: faqserv@bloom-picayune.MIT.EDU
  17. Xref: bloom-beacon.mit.edu comp.unix.shell:9365 news.answers:17280 comp.answers:4419
  18.  
  19. Archive-name: unix-faq/shell/intro
  20. Version: $Id: intro,v 2.3 1993/09/01 23:41:31 tmatimar Exp $
  21.  
  22. This article is a monthly attempt to remind potential posters about
  23. what is appropriate for comp.unix.shell.  If you would like to make
  24. any suggestions about the content of this article, please contact
  25. its maintainer at tmatimar@empress.com.
  26.  
  27. Many FAQs, including this one, are available on the archive site
  28. rtfm.mit.edu in the directory pub/usenet/news.answers.
  29. The name under which a FAQ is archived appears in the "Archive-Name:"
  30. line at the top of the article.  This FAQ is archived as
  31. "unix-faq/shell/intro".
  32.  
  33. Companion articles include the answers to some Frequently
  34. Asked Questions.  You may save yourself a lot of time by reading
  35. those articles before posting a question to the net.
  36.  
  37. If you have not already read the overall Usenet introductory material
  38. posted to "news.announce.newusers", please do.  Much of this article
  39. overlaps with the common sense guidelines posted there.
  40.  
  41.          Should I Post My Shell Question to the Net?
  42.  
  43. Often the answer is "No, you can get an answer a lot faster without
  44. posting a question." Before you post, you should try -
  45.  
  46.     o Reading the manual for your system.  Some day you may encounter
  47.       the phrase "RTFM", which stands for "Read the Fine Manual"
  48.       (except 'F' doesn't really stand for "Fine").  If you ask
  49.       someone a question and they tell you to RTFM, it's an
  50.       indication that you haven't done your homework.  For instance,
  51.       if you are trying to make a script run under csh instead of sh,
  52.       check the man page for "csh".  It might tell you what you need
  53.       to know.
  54.  
  55.       When people use terminology like "read(2)", they are referring
  56.       to the "read" man page in section 2 of the manual (which you
  57.       would see by using "man 2 read").
  58.  
  59.     o Finding a knowledgeable user at your site.  Many sites have
  60.       at least a few shell experts who will be happy to help you
  61.       figure out how to specify that a script should be run by csh.
  62.       Many larger sites, particularly universities, may even have
  63.       paid consultants whose job is to help you with these problems.
  64.       Check with them first.
  65.  
  66.     o Find a good introductory book on Unix shells and shell programming.
  67.       There are plenty of such books available, and you will save yourself
  68.       a lot of trouble by having one handy and consulting it frequently.
  69.       (Question 1.5 in the companion articles will let you know
  70.        where you can find a list of good books.)
  71.  
  72. Please remember that the comp.unix.* newsgroups are read by over 80,000
  73. people around the world, and that posting a question to this group will
  74. cost a lot of time and money by the time your article is distributed to
  75. Asia, Australia, Europe (west and east), Africa, the middle east,
  76. all corners of North, South and Central America and even Antarctica.
  77.  
  78. Also, some people receive these newsgroups as part of a mailing list
  79. rather than a newsgroup.  If you're one of these people, please don't
  80. send a "Remove me from this list" or "UNSUBSCRIBE"  message to the
  81. wrong place.  Take the time to figure out where you're getting this
  82. stuff from, and send your request to the mailing list maintainer, *not*
  83. to the list or newsgroup itself!  Ask your local postmaster for help.
  84. (One of the answers in the companion articles deals with the details of
  85. the mailing list.)
  86.  
  87.                To Which Newsgroup Should I Post My Question?
  88.  
  89. The choice of newsgroup is harder than it used to be.  In the old days,
  90. you just had to choose between "comp.unix.questions" and
  91. "comp.unix.wizards".  Now there are a variety of more specific groups.
  92. This group, "comp.unix.shell" is only for questions relating to any of
  93. the Unix shells and shell programing.  Other groups each have their own
  94. mandates.
  95.  
  96. Choose one of the following groups carefully.  If you aren't sure where
  97. your question belongs or if your question is not specific to some
  98. particular version of Unix, try "comp.unix.questions".  Many
  99. knowledgeable Unix wizards read that group and will be able to help you.
  100.  
  101. Here are the capsule descriptions of various groups you might consider
  102. (extracted from a monthly posting to "news.announce.newusers")
  103.  
  104. comp.unix.shell         Using and programming any UNIX shell.
  105.  
  106. comp.unix.questions     General questions from UNIX users and sysadmins.
  107.             If your question isn't a really good match for one of
  108.             the groups below, post it here.
  109.  
  110. news.answers        Repository for periodic USENET articles. (Moderated)
  111.             This article is crossposted there.
  112.             Do not try to post here unless you're
  113.             posting a list of FAQ's and their answers.
  114.  
  115. comp.lang.c             Discussion about C.
  116.  
  117. comp.sources.unix       Postings of complete, UNIX-oriented sources. (Moderated)
  118. comp.std.unix           Discussion for the P1003 committee on UNIX. (Moderated)
  119. comp.unix               Discussion of UNIX* features and bugs. (Moderated)
  120. comp.unix.admin         Administering a Unix-based system.
  121. comp.unix.aix           IBM's version of UNIX.
  122. comp.unix.amiga        Unix on the Commodore Amiga
  123. comp.unix.aux           The version of UNIX for Apple Macintosh II computers.
  124. comp.unix.bsd           Discussions relating to BSD UNIX.
  125. comp.unix.internals     Discussions on hacking UNIX internals.
  126. comp.unix.large         UNIX on mainframes and in large networks.
  127. comp.unix.misc          Various topics that don't fit other groups.
  128. comp.unix.msdos         MS-DOS running under UNIX by whatever means.
  129. comp.unix.programmer    Q&A for people programming under Unix.
  130. comp.unix.sysv286       UNIX System V (not XENIX) on the '286.
  131. comp.unix.sysv386       Versions of Unix (not Xenix) on Intel 80386-based boxes.
  132. comp.unix.ultrix        Discussions about DEC's Ultrix.
  133. comp.unix.xenix.misc    General discussions regarding XENIX (except SCO).
  134. comp.unix.xenix.sco     XENIX versions from the Santa Cruz Operation.
  135.  
  136. comp.unix.wizards       In-depth discussions of advanced unix topics.
  137.             People should not post to this group unless they
  138.             have used unix as a user, sysadmin and know details
  139.             of the kernel, and how different unix kernels differ.
  140.             In other words, don't post to comp.unix.wizards.
  141.  
  142.           What Information Should I Include?
  143.  
  144. It's hard to include too much information.  There are hundreds of
  145. different systems out there, and they all have less in common
  146. than you might think.  If you have a problem and are posting an
  147. article, please be sure to mention:
  148.  
  149.     o A descriptive subject line.  Many people will decide whether
  150.       to read your article solely on the basis of the subject line,
  151.       so it should be a good statement of your problem.
  152.  
  153.       NOT GOOD                          GOOD
  154.  
  155.       "Help"                            "How do I port csh scripts to ksh?"
  156.       "Csh question"            "csh dumps core when I use '$<'"
  157.  
  158.     o What computer you are using, what specific version of the
  159.       operating system it uses, and to what shell the question
  160.       pertains.  For instance,
  161.  
  162.         SunOS 4.0.1, Sun 3/50, tcsh 6.00.03
  163.         4.3BSD-tahoe, Vax 11/780, rc 1.0
  164.         SVR3.2, 3b2, sh 4.2
  165.  
  166.     o If possible, the *exact* text of any error message you
  167.       may have encountered.
  168.  
  169.       WRONG                RIGHT
  170.  
  171.       "My csh script doesn't run"    "When I type 'scriptname', I get
  172.                       sh: scriptname: This isn't a shell script.
  173.                       What does this mean?  It isn't in
  174.                       the man page.  This is using crash 3.14
  175.                       under Mueslix 9.3 on a Fax 68086502"
  176.  
  177. It's a good idea to post unrelated questions in separate articles,
  178. so that people can keep different discussions separate.   It's also
  179. a *very* good idea to include a line or two like this:
  180.  
  181.     "Please mail your answers to me and I'll summarize what I get
  182.      and post the results to comp.unix.shell."
  183.  
  184. This prevents many identical responses from different users to the
  185. same question from clogging up the newsgroup.  And make sure
  186. you really summarize what you get - don't just concatenate
  187. all the mail you've received.
  188.  
  189. It's also a good idea to read comp.unix.shell for at least a couple
  190. of weeks after you post your article to see what followup articles
  191. are posted.
  192.  
  193.                 Should I Post an Answer to a Question?
  194.  
  195. It's very tempting to post an answer to a question you read on the net,
  196. especially when you think "Aha, finally - a question I can answer!"
  197. Consider though that when a simple question is asked, such as the
  198. sort answered in the companion articles, many other people around the
  199. world already know the answer and may be posting their own reply.
  200. In order to avoid dozens of replies to simple questions, please
  201. wait a day or so and see if anyone else has already answered
  202. the question.  If you have something special to contribute, please
  203. do so, but make sure you're not duplicating something someone else has
  204. already done.
  205.  
  206. You should feel free to reply to any question >by email<.  Even if
  207. the user gets 200 responses to his question, at least the load on the
  208. rest of the net is minimized.
  209.  
  210.                     What About Posting Source Code?
  211.  
  212. Posting small amounts of example code is fine (use comp.sources.unix to
  213. distribute complete programs) - but please make sure that your code
  214. runs (or at least compiles) properly.  Don't just type it in while
  215. editing your posting and hope it will work, no matter how sure you are
  216. that it will.  We all make mistakes.
  217.  
  218.                         What About Those People
  219.        Who Continue to Ask Stupid or Frequently Asked Questions
  220.          In Spite of The Frequently Asked Questions Document?
  221.  
  222. Just send them a polite mail message, possibly referring them to this document.
  223. There is no need to flame them on the net - it's busy enough as it is.
  224. -- 
  225. Ted Timar - tmatimar@empress.com
  226. Empress Software, 3100 Steeles Ave E, Markham, Ont., Canada L3R 8T3
  227.